1. Field of the Invention
The present invention relates in general to integrated circuit (IC) testers and in particular to an IC tester having a memory for recording data indicating the status of a test program being executed.
2. Description of Related Art
Failure Analysis For Program Context
A typical integrated circuit (IC) tester organizes a test of a digital IC device under test (DUT) into a succession of test cycles. During each test cycle each tester channel may send a test signal to a DUT terminal or may sample DUT output signal at a DUT terminal to determine whether it is of an expected state. The sequence of activities carried out by each tester channel is determined by a sequence of data values (vectors), each defining the actions the tester channel is to carry out during one cycle of a test. Since tests can span many millions of test cycles, a vector sequence may include many millions of vectors. Since a tester would require a very large vector memory to store such a large vector sequence, many testers use algorithmic pattern generators to produce the vector sequences as they are needed during a test. An algorithmic pattern generator includes a program memory for storing a program for generating a sequence of data. An instruction processor included in the pattern generator executes the program to produce the data sequence during a test. The data sequence can be used directly as a vector sequence or to control addressing of a vector memory that reads out vectors as needed during a test.
Vector sequences (or vector memory addressing sequences) for many tests include repetitive sections that are more efficiently represented by repeat, loop and subroutine call instructions. For example a section of a vector sequence having 1024 successive one-byte vectors of value X can be represented in an algorithmic program as an instruction such as xe2x80x9cREPEAT 1024 Xxe2x80x9d. Depending on the manner in which it is encoded, this instruction can be represented in a program by a few bytes instead of 1024 bytes.
A entire section of a vector sequence that is repeated can be represented as an instruction loop. For example a 4096 byte section of a vector sequence in which four one-byte vector sequence W, X, Y and Z is repeated 1024 times can be represented with a relatively few bytes by the following lines of code:
LOOP 1024
W
X
Y
Z
LOOPEND
A sequence of 26 vectors A, B . . . Y, Z that is repeated at many different locations throughout a main vector sequence can be represented in a program as a single callable subroutine. In such case the 25-vector sequence need only appear once in the program; each occurrence of the 26-vector sequence may be represented in the program by a simple subroutine call instruction requiring only a few bytes.
While algorithmic pattern generators allow IC testers to avoid having to store large vector sequences, they make it more difficult for test engineers to analyze test results. The vector each tester channel receives before the start of each test cycle indicates the DUT output signal state the tester channel is to expect during the test cycle. If the DUT output signal fails to match that state, the channel asserts an output FAIL signal that is processed to provide test results data to a test engineer. In addition to learning whether a DUT has failed a test, a test engineer often wants to determine why the DUT failed the test. To do that, the test engineer would like to know both the DUT output terminal failed and the point in the test program at which the failure occurred. That last bit of information, the xe2x80x9cprogram contextxe2x80x9d of a failure, tells the test engineer the conditions under which the DUT failed.
IC testers can typically tell the test engineer the test cycle in which a particular DUT output signal failed. When testing an IC, an IC tester usually maintains a count of the number of test cycles it has carried out, and when one of the tester channels asserts a fail signal during some particular test cycle, the tester produces output data indicating both the channel that detected the failure and the current test cycle count.
When we know the test cycle in which the failure occurs, it is usually possible to determine the point in the test program that caused the DUT failure. However when the test program contains many repeats, nested loops, and subroutine calls it is not easy to do that quickly. Failure analysis software designed to locate a point in a program that produced a vector for a particular test cycle typically simulates execution of the test program while keeping track of such information as the current program memory address, repeat count, loop count values, stack contents etc., until it reaches the test cycle of interest. This information can then be used to determine the particular point in the program at which the DUT failed. However it can take longer for the simulation software to find the point of interest in the test program than it did for the tester to test the DUT. What is needed is a test system that provides sufficient information to enable a test engineer to quickly determine the program context of a test failure.
Some testers permit conditional branching during a test in response to test results, and in such case the course of the test depends on how the DUT behaves during the test. When a tester program is subject to conditional branching, failure analysis software cannot determine the program context of a failure from the cycle count because it does not have access to the test results that controlled branching during the test. Thus it is not always possible for failure analysis software to correlate a test cycle to a particular point in a test program.
What is needed is an integrated circuit tester architecture that provides information that enables failure analysis software to determine the program context of a failure when a test involves conditional branching.
Failure Analysis for Spare Row/Column Replacement
Random access memories (RAMs) are typically formed as arrays of rows and columns of memory cells. The input address to a RAM identifies the particular row and column of the cell to be read or write accessed. Some RAMs include spare rows and/or columns of memory cells so that when one of the RAM""s cells is defective, the RAM can be modified to replace the row or column of a defective cell with one of its spare rows or columns. As it tests such a RAM, a RAM tester stores pass/fail data indicating whether each memory cell has passed or failed the test. After the RAM has been fully tested, the cell pass/fail data is provided to failure analysis software that determines how to best allocate spare rows and columns when repairing the RAM. Conventional RAM testers employ a memory as large as the RAM being tested for storing the pass/fail data for each cell of the RAM. After the RAM has been fully tested, the entire contents of the pass/fail data memory is transferred to a host computer running the failure analysis software. It would be beneficial to provide a RAM tester architecture than can provide failure analysis software with enough information to determine how to allocate spare rows and columns without having to include a memory large enough to store pass/fail data for each cell of the RAM under test. It would also be desirable if such information were compact so that it could be transferred quickly to the host computer.
Block Failures
Some non-volatile memories are organized into blocks of memory with each block having a separate block address. Thus a particular memory cell will have a block address, a row address and a column address. Such memory can be reconfigured to avoid using blocks that may have a minimum number of defective cells. To avoid having to provide a large memory for storing pass/fail data for all cells of all blocks a memory tester typically separately tests each memory block and sends pass/fail data to a host computer after each block test. Failure analysis software in the host computer then decides how to reconfigure the RAM to avoid using failed blocks based on the number of failed cells in each block. This process can be time-consuming since the tester has to be stopped and restarted once for each memory block. What is needed is a tester architecture that, with employing a large pass/fail memory, fully tests all blocks and then transmits a relatively small amount of data to the host computer sufficient to enable the failure analysis software to determine the number of cell failures in each memory block.
An integrated circuit (IC) tester in accordance with the invention employs a pattern generator including an instruction processor executing an algorithmic program stored in a program memory. The program defines a test instruction sequence produced by the instruction processor for controlling the course of a test being performed on an IC. In the course of executing the program, the instruction processor stores in various registers and counters xe2x80x9cprogram statusxe2x80x9d data used to keep track of program execution. The status data may include, for example, the current program memory address, loop and repeat counts, return addresses and the like.
In accordance with one aspect of the invention, the pattern generator also includes a random access xe2x80x9cprogram statusxe2x80x9d memory controlled by the instruction processor for receiving and storing selected portions of the program status data at selected points during a test. Analysis software can use this information after the test, for example, to determine how the program conditionally branched during the test to determine the program context of failures.
In accordance with a second aspect of the invention, the algorithmic program defining the data sequence controlling test activities during each test cycle also defines a sequence of status memory instructions. These instructions tell the instruction processor which portion, if any, of the program status data is to be stored in the status memory during each test cycle, the address at which the status data is to be stored, and the conditions that trigger status data storage.
In accordance with a third aspect of the invention, the tester also includes a set of address counters controlled by the pattern generator for providing memory addresses when the tester is testing a random access memory (RAM). The program instructions can tell the status memory to record the address data generated by selected counters when a cell of the RAM being tested fails a test. The address data stored in the status memory can, for example, provide a basis for determining how to allocate the RAM""s spare rows and columns for determined which of its memory blocks should not be used.
It is accordingly an object of the invention to provide a means for allowing a tester to store selected program status data that may allow test analysis software to determine the course of a test involving conditional branching so that it may determine the program context of DUT failures or other detectable events.
The concluding portion of this specification particularly points out and distinctly claims the subject matter of the present invention. However those skilled in the art will best understand both the organization and method of operation of the invention, together with further advantages and objects thereof, by reading the remaining portions of the specification in view of the accompanying drawing(s) wherein like reference characters refer to like elements.